Today's Access Management solutions generally have a service centric view. This means that the primary goal is typically to protect data and services on the backend service or provisioning layer. This generally makes sure that access checks are always performed on the granularity of the services offered regardless of the consumer that is requesting these services. Also, this often makes it difficult to do user interface (UI) specific optimizations for UIs that cross service boundaries (e.g., from one data provider to another, etc.). For example, typically for each service request a UI makes to a backend server, one or many authorization or security checks must be made within the service execution layer.
Often for every data access service (e.g., a read or a write, etc.) a requesting device or UI must provide appropriate authorization or credentials to access the desired data. On service provisioning side (also known as backend side) these UI centric service requests are translated into data centric service requests. This UI model translation and the belonging data service calls are performed by the backend UI framework. Typically one UI service call is disassembled into multiple core data service calls. The different results of these multiple core service calls is then assembled into the UI response and sent back to client side. Today for each of these core service calls the core service layer will perform a separate access control not knowing the relationship between all these calls. This may cause a bad response time and a large amount of overhead for processing the access control for each core service call separately although they potentially perform semantically redundant checks (e.g. checking parent AND child data even though both are displayed together in the same row of a table).